home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0082 / 86.txt < prev    next >
Text File  |  1997-04-16  |  12KB  |  251 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Tue, 23 Jan 90       Volume 90 : Issue   86
  4.  
  5. Today's Topics:
  6.                             ARC 6.02 bugs
  7.                              dissassembly
  8.                         GNU/Sozobon C question
  9.                                Mac ROMS
  10.                         Need Hard Disk Wisdom
  11.                        writing "tee" for the ST
  12. ----------------------------------------------------------------------
  13.  
  14. Date: 22 Jan 90 21:17:19 GMT
  15. From: ucsdhub!hp-sdd!hp-pcd!hplsla!andyc@ucsd.edu  (Andy Cassino)
  16. Subject: ARC 6.02 bugs
  17. Message-ID: <5440098@hplsla.HP.COM>
  18.  
  19. |
  20. | It turns out that I can not get ARC 6.02 to work with any of the graphical
  21. | shells I have for ARC (ARCSHELL, ARCGSH21, UNARC). All of them produce either
  22. | two or four bombs (it keeps changing) when they go to execute ARC. The older
  23. | version of ARC (v5.21b I think) runs fine with all of these shells.
  24. |
  25. | Has anyone else had trouble with ARC V6.02 running under these shells? I
  26. | assume it is working for most people since no one else has mentioned the
  27. | problem.
  28. |
  29. | ----------
  30.  
  31. I'm using ARCSHELL 2.1 with ARC 6.02 with no trouble under TOS 1.4. There is
  32. supposed to be ARCSHELL 2.1b out now to rectify some bug or another with
  33. ARC 6.02, but I haven't seen the bug nor do I have v2.1b....
  34.  
  35. Disclaimer: The opinions expressed herein are those solely of the author,
  36.             who has no pecuniary interest in the companies, products,
  37.             or publications mentioned above.
  38.  
  39.     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  40.     % Andy Cassino                                                  %
  41.     % uucp: hplabs!hplsla!andyc  domain: andyc%hplsla@hplabs.hp.com %
  42.     % Hewlett-Packard              Lake Stevens Instrument Division %
  43.     % 8600 Soper Hill Road                   Everett, WA 98205-1298 %
  44.     % (206) 335-2211                                                %
  45.     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  46.  
  47. ------------------------------
  48.  
  49. Date: 23 Jan 90 17:04:23 GMT
  50. From: voder!pyramid!athertn!alex@ucbvax.Berkeley.EDU  (Alex Leavens)
  51. Subject: dissassembly
  52. Message-ID: <17035@laurel.athertn.Atherton.COM>
  53.  
  54. Daniel Glasser writes:
  55.  
  56. >In my honest opinion, biased as it may be, the MWC manual is the single
  57. >best volume for programming the ST published to date.  It needs revision,
  58. >bugfixing, and maybe some other tweeking (new GEM examples, etc.) and
  59. >the compiler should be updated, but it is still a very good package at a
  60. >good price.
  61.  
  62. Seconded.  Whenever I'm writing GEM code, the first thing I look in
  63. is the MW manual.  If I can't find it there, I look in the HitchHiker's
  64. Guide, or somewhere else.  But I can usually find it in MW.  It's
  65. really good.
  66.  
  67.  
  68. --
  69. |-------------------------------------------------------------------------|
  70. |--alex | alex@Atherton.COM |  Caution!  Falling Opinions, next 6 miles   |
  71. |        Now who are you gonna believe--me, or your own lyin' eyes?       |
  72. |-------------------------------------------------------------------------|
  73.  
  74. ------------------------------
  75.  
  76. Date: 23 Jan 90 19:34:36 GMT
  77. From:
  78.  zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!w
  79.  atserv1!watdragon!tiger!swklassen@tut.cis.ohio-state.edu  (Steven W. Klassen)
  80. Subject: GNU/Sozobon C question
  81. Message-ID: <20086@watdragon.waterloo.edu>
  82.  
  83. In article <894@per2.UUCP> dag@per2.UUCP (Daniel A. Glasser) writes:
  84.  
  85. >A large part of the speed "problems" that the MWC compiler has is because of
  86. >this history.  A version (built from the same sources) ran on a PDP-11 as
  87. >a cross compiler until version 3.  The PDP-11 has only 64k of virtual
  88. >address space.  The compiler, therefore, uses disk files to store intermediate
  89. >code and chains between programs to do various stages of compilation.
  90. >The advantage to this is that the MWC compiler can run effectively in systems
  91. >with limited memory (512k with DAs loaded) and can handle programs larger than
  92. >available memory.  I've linked an 800k program on a 520 with MWC.
  93.  
  94. The speed problem can be minimized through the use of the ram-disk
  95. (if you have the memory for it - ie. at least a 1040).  A very nice
  96. ram disk is included in the MWC package.  The 'disk' files used for
  97. intermediate code and stuff are then written in the ram disk, ie. almost
  98. as fast as using main memory directly (there may be some overhead in
  99. the maintenance of the ram disk but it likely isn't too bad).  Multiple
  100. passes through the data is very slow on a disk but not bad at all on
  101. a ram disk.
  102.  
  103. I must admit, however, that I haven't made any comparisons between
  104. compile speed of different compilers.  I consider that issue to
  105. be of lower priority than run speed (ie. I will put up with slower
  106. compile times if I get better run times as a result.).
  107.  
  108.  
  109.  
  110. Steven W. Klassen                       +-----------------------------+
  111. Computer Science Major                  | Support the poor...buy fur! |
  112. University of Waterloo                  +-----------------------------+
  113.  
  114. ------------------------------
  115.  
  116. Date: 22 Jan 90 16:56:07 GMT
  117. From: njsmu!telesci!cciolori@princeton.edu  (Christopher Ciolorito)
  118. Subject: Mac ROMS
  119. Message-ID: <938@telesci.UUCP>
  120.  
  121.  Perhaps this is a silly question, but I will ask it anyway.
  122.  
  123.  Everyone knows that the ST can mimic the Mac with the right hardware,
  124.  software, and of course the Mac ROMS.
  125.  In addition, a message had been posted which indicated that the new
  126.  TT machine would allow the ST to run Mac software at high speed,
  127.  which could give apple some stiff competition if Atari took advan-
  128.  tage of this, and made the public aware that this software/hardware
  129.  exists.
  130.  A great ad campaign would tell potential buyers that the Atari, in
  131.  addition to running its own software, could also run IBM, and Mac
  132.  stuff too!
  133.  
  134.  ....then I got to thinking...let's say that Atari did begin take
  135.  advantage of this oppurtunity, and in fact were hurting Mac II sales.
  136.  Couldn't Apple just say FORGET IT and NO LONGER SELL anyone Mac
  137.  ROMs? Or would it be more profitable to allow Atarians to continue
  138.  to buy them? I mean, they are making money when people buy them,
  139.  although I am sure they would rather be selling THIER computers
  140.  along with them.
  141.   Just a thought...what does everyone think?
  142.                            Chris
  143.  
  144. ------------------------------
  145.  
  146. Date: Tue, 23 Jan 90 10:27:54 -0900
  147. From: <FNDDR%ALASKA.BITNET@CUNYVM.CUNY.EDU>
  148. Subject: Need Hard Disk Wisdom
  149.  
  150. In <7500012@m.cs.uiuc.edu>, totty@cs.uiuc.edu writes:
  151. >       I'm sure this subject has been covered many times, but I
  152. >       haven't been reading this group for a long time.  I am
  153. >       interested in obtaining info from anyone about building
  154. >       hard disks fro the ST.  Advice on interfacing, drive/controller
  155. >       recommendations, power supply choices, cases, and difficulties
  156. >       about the ST.  Please email to me if the subject has been beaten
  157. >       to death.
  158. Not beaten to death recently, I think.
  159. I've built three 60 MB drives using the BMS-200 kits from E. Arthur Brown.
  160. EABCo sells the BMS host adapter, case, and power supply...you buy the
  161. drive elsewhere.  I bought ST-277N drives from Hard Drives International
  162. (they advertise in Computer Shopper and Byte).
  163. It takes less than an hour to put the drive together and install it, if
  164. you follow EABCo's somewhat sparse instructions correctly.  Construction
  165. consists of attaching the DMA cable, a ribbon cable, two power supply
  166. connectors, and mounting the drive and host adapter in the case.  The
  167. BMS software has a nice boot-holdoff feature that waits until the drive
  168. spins up before starting the boot process, so you don't have to power up
  169. the drive and ST separately.  Other than that, the BMS software is pretty
  170. basic.  There's a battery-backed clock on the host adapter which can be
  171. read from a program in the auto folder.  Some considerations:
  172. 1. The cost of everything plus shipping is much cheaper than comparable
  173.    drives from Supra or Atari, but there are other options, such as ICD
  174.    and Toad Systems, which are in the same price range as BMS.
  175. 2. Two of the drives worked fine the first time, but a third had a flakey hard
  176.    drive which sort of worked for a few weeks, then died.  HDI replaced it,
  177.    but I found arranging the replacement very annoying.  Calling HDI's
  178.    support line seems to involve a mandatory wait of 20-30 minutes on hold,
  179.    and it isn't an 800 number.  It also took them a month to come up with
  180.    a replacement, compared to two days to ship the original.  In contrast,
  181.    both EABCo and BMS were very helpful and responsive in diagnosing the
  182.    problem.
  183. 3. The BMS software is very basic, limited to 4 partitions @ 16 MB.  The
  184.    EABCo version simplifies the BMS package by supplying special setup
  185.    programs for Seagate SCSI drives ONLY; they omit "confusing" information
  186.    about setting up other types of drives.  If you want to use another brand
  187.    of drive, you should buy the BMS-200 directly from BMS.  BMS suggests using
  188.    Atari's hard disk software if you want bigger or more partitions...
  189.    apparently they aren't planning to support those options anytime soon.
  190. 4. With the EABCo setup, there is a spare power supply connection.  You should
  191.    be able to add a second SCSI hard drive for the price of the drive, a
  192.    SCSI ribbon cable, and a second case (no room in the first case due to
  193.    the host adapter).  How you could get the power and SCSI cables to the
  194.    second drive is left as an exercise for the ambitious.
  195. The main advantage of the SCSI solution is ease of upgrade.  You can buy a
  196. small SCSI drive and replace it with a big one later, and you have a good
  197. chance of selling the original in the pc/mac marketplace.  I think that the
  198. BMS system from EABCo is a reasonable choice, particularly if you enjoy
  199. tinkering, but check out ICD and Toad options as well.
  200. Good luck,
  201. Don Rice
  202. FNDDR@ALASKA.bitnet
  203. Notes:
  204.  EABCo = E Arthur Brown Co, 612-762-8847
  205.  BMS = Berkeley Micro Systems, 415-547-2191
  206.  HDI = Hard Drives International, 800-234-DISK
  207.  ICD, Toad: look them up in your favorite ST mag
  208.  
  209. ------------------------------
  210.  
  211. Date: 23 Jan 90 18:08:06 GMT
  212. From: mcgill-vision!quiche!calvin!depeche@BLOOM-BEACON.MIT.EDU  (Sam Alan EZUST)
  213. Subject: writing "tee" for the ST
  214. Message-ID: <2027@calvin.cs.mcgill.ca>
  215.  
  216. I asked this question a little while ago and got some responses from
  217. people who had good intentions but not enough facts about how to solve
  218. the problem...
  219.  
  220. How hard could it be to get a program to send all its output to
  221. the a file or the printer WITHOUT changing the screen output?
  222.  
  223. i.e. I'd like to direct output to a file but I also want to see what it
  224. is on the screen, so I can run interactive programs and save all the output.
  225.  
  226. This would be easy if there was a shell which supported pipes, but contrary
  227. to popular belief, GULAM does not support such, and neither does
  228. mwc shell (it simply redirects the output of one program until it is
  229. finished, and then runs the second taking the file it created before
  230. and redirects the input of it to this file.) A real pipe needs multitasking,
  231. I guess.
  232.  
  233. Do standard output calls use a system call to print characters on the screen?
  234. if so , perhaps changing the vector for that call to another routine
  235. which first sends the character to the printer and then calls the
  236. original system call would do the trick.
  237.  
  238. I am a novice in this area of system programming - I only know the theory.
  239. Has anyone actually done something like this?
  240.  
  241.  
  242. --
  243. S. Alan Ezust                                   depeche@calvin.cs.mcgill.ca
  244. McGill University School of Computer Science -  Montreal, Quebec, Canada
  245.     If pro is the opposite of con, what's the opposite of progress?
  246.  
  247. ------------------------------
  248.  
  249. End of INFO-ATARI16 Digest V90 Issue #86
  250. ****************************************
  251.